Paradigm-Shift Issues, Installing Editors, and More
By the Apple Computer OpenDoc Human Interface Team
As published in the May 1996 Apple Directions
Recently, there were several questions about the OpenDoc user interface in the OpenDoc Interest Group. We think you’ll want to know about the OpenDoc topics these questions address.
Q: The other day I was showing OpenDoc to some users with moderate experience, and they were very confused by several aspects of the user interface. They weren’t aware of the whole concept of stationery, so they couldn’t understand how to start up a new “application.” They said, “I want to write a memo; where is the OpenDoc word processor?”
A: Our studies show that people learn the stationery concept after very little training. What users have to do to start using OpenDoc isn’t much different from what they do in today’s application model.
On the other hand, users do have to learn about stationery somehow. Here’s what we’re doing to help. We will provide a tutorial to cover the basic concepts of OpenDoc, including stationery. In addition, OpenDoc will support Apple Guide 2.1, which can be used by your editors to provide help for your parts. Apple Guide includes such topics as “How do I create a document?”.
However, the first exposure your users will have to stationery will be through Read Me files and other documentation you provide. You may want to include the following paragraph in your documentation. (Of course, you’ll have to modify the picture to match your product.)
Stationery:
You use stationery to open a new document (by double-clicking the stationery icon) and to add a part to a document (by dragging the stationery icon into the document). You can find stationery in the Stationery folder inside your hard disk. A stationery icon looks like this:
Finally, your Read Me file should tell your users to see Apple Guide for more details.
Q: Why don’t editors behave more like applications? For example, I want to double-click an editor to create a new document.
A: In OpenDoc, editors are more like extensions than applications. Because of this difference, we designed the icons of editors to look more like those of extensions. Users don’t expect to double-click an extension like QuickTime to start a QuickTime movie viewer. In fact, when an extension is double-clicked, it doesn’t launch anything; instead, it displays a message explaining that it is a system extension that adds capabilities to the system. Our OpenDoc editors have a similar message, but a bug in some versions of the system sometimes interferes with it being displayed.
The most important thing to remember is that part editor icons are system files that users should never have to work with just as users never work with system extensions except during installation or deinstallation.
Instead, the user interface to OpenDoc parts is through stationery. When explaining to users the analogy between using applications and using parts, tell them that double-clicking a stationery icon is like double-clicking an application icon. Typically, users don’t need to take any direct actions with editors. This is why it’s important that part developers provide an installer—so that users don’t have to confront editors.
A key advantage of stationery is that it allows you to provide some useful initial content. For example, you could provide “time card” stationery that actually contains a text part and a spreadsheet part, perhaps with a database connection part linked to the spreadsheet. So, in this case, there isn’t a single editor that corresponds to the time card but a collection of editors. The stationery saves the user the time and effort of creating a standard template of different parts each time they want to create a Time Card.
Users or system administrators can also create their own task-specific stationery. For example, a company’s letterhead stationery might contain a page layout part, a graphic part, and a text part. Because of this additional capability, we believe stationery is a very powerful design component that allows users to go far beyond double-clicking an editor icon.
Q: Users don’t seem to grasp the idea that these are compound documents containing multiple part editors. What can be done about this?
A: The user doesn’t need to understand that there are multiple parts being displayed and edited by multiple part editors. All the user needs to know is, “If I want to work on the spreadsheet cell, I just click in it.”
Our studies show that the concept of activation is less important than that of selection—in effect, activation is really a by-product of the object/action model. For example, suppose the user wants to boldface some text. The user must first select the text (the object) and then choose the Bold command (the action) from the menu. Selecting the text causes the text part to become active; the active part editor then shows all the applicable tools to the user. In today’s GUI (graphical user interface) system, users must learn how to select—not how to activate—to use any system. So don’t try to explain the compound-document model; just explain to the user how to get things done: just select what they want to work on first.
Q: For users, Macintosh Drag and Drop is very difficult to use on 14-inch monitors. They spend a lot of time moving windows around and scrolling to put documents in place. So why is it such an important part of OpenDoc?
A: Macintosh Drag and Drop is an accelerator that users like a lot, but it isn’t the only method of copying or moving content. Copy and paste operations are still available. Users can also insert entire documents into the current document by means of an Insert command. In addition, Copland will add new features—spring-loaded folders and pop-up windows—that will make the drag-and-drop behavior more useful on small monitors. (For details, see “Looking Forward to the Copland User Experience” on page 1 of the April 1996 issue of Apple Directions.)
Q: What some users miss the most is using a tool bar with different data types to create new content. How can we address this issue in OpenDoc?
A: As in the application world, tool palettes can be used to add new content. We encourage developers to continue to provide tool palettes in OpenDoc with the following difference: Instead of reimplementing common function in the code, your part editor should use any part editors that perform the same function are are already present on the user’s system. For example, a draw editor usually needs to have a tool for creating text. Instead of the developer providing the text support, the tool just creates a text part and uses the default text part. For more details, see the OpenDoc Q&A in the May 1995 issue of Apple Directions.
Q: The launch time for OpenDoc is very slow. Users usually close documents once they finish using them; after they close the last OpenDoc document on the screen and then open a new one, they have to watch the OpenDoc startup screen for several seconds.
A: We agree! Faster launching is a high priority for us, and the engineers are working on this.
Q: OpenDoc isn’t visually different or appealing. Although it is supposed to cause a revolution, it’s visually the same as before. So, you have almost the same screens as normal applications but with slightly different rules. How are users going to know that OpenDoc is giving them something they can’t get from traditional applications?
A: If OpenDoc were dramatically different from today’s applications, users would have problems adapting to it. We did not intend OpenDoc to look different; the design of OpenDoc focused on allowing you to build different and better applications. There are visual clues, of course, that the user is working with OpenDoc parts; the process menu will show an OpenDoc part icon when a part is active, and the special OpenDoc border for activation is also a very visible clue. In addition, OpenDoc will use Copland’s new visual design. Just a note—be careful about using non-standard controls, menus, and windows because they may not be visually compatible with Copland.
Q: Users have problems getting away from the application-oriented way of thinking. They used to think in terms like "I’ve saved my memo in Word" or "That document was in Excel.” Having documents that are independent of particular applications is confusing. Actually, many users save their files in folders with names like "Word documents," "ClarisWorks documents," and so on. Isn’t this going to get in the way of user acceptance of OpenDoc?
A: We don't think so—our studies show that existing users quickly learn OpenDoc. Part of the reason for the confusion you are seeing is that there are no real part editors available today. Most of the sample part editors on the DR4 version of OpenDoc don’t completely follow the OpenDoc HI guidelines. So right now, chances are you haven't seen how OpenDoc is supposed to work. Apple’s own OpenDoc parts should be out soon, and they can be used as benchmarks for good HI design.
Q: What happens when users stop using an editor or they install a new version of an editor? If users are not supposed to see editors, won’t the editors just collect in the Editors folder long after users stop using them?
A: Yes, that is possible. So, we suggest that you provide a way to deinstall your editor so that the Editors folder doesn’t become overloaded. For installation over a previous version, consider asking users if they want to keep the old version before the installation process removes it. Some users may need this feature.
We are aware of dependencies between editors and are looking at clean ways of deinstalling. At the earliest, we will probably have a solution to this problem by the time of the Copland release.
Q: We are currently developing our software as OpenDoc parts, but I’m concerned about some of these editor management issues. While I agree with many of the philosophical reasons for treating editors similarly to system extensions, there are practical ramifications that present problems. In particular, the OpenDoc design is oriented toward a single fixed hard-drive system, and that doesn’t scale well to other scenarios. For example, I have an internal and an external hard drive. Mostly, I start up from the internal drive, but occasionally I start up from the external drive. My applications are always available regardless of which hard drive I start up from—which is not necessarily true with OpenDoc. Forcing users to install all software in the System Folder of each bootable disk is a serious restriction on their ability to customize their workspaces.
A: We considered the very issues you bring up. The standard OpenDoc installation will work fine for most users, but you’re describing a “power user” situation. Fortunately, it turns out that OpenDoc has a solution for it as well. According to the OpenDoc Programmer’s Guide (page 633),
[you must] install part editors and part viewers in the Editors folder, which may be either in the System Folder on the user’s startup volume or on the root of any mounted volume. . . .
According to this statement, you may have an Editors folder at the root level of an external volume or a server—and you don’t have to have a System Folder on each external volume or server just to accommodate OpenDoc. In your situation, the solution would be to move the Editors folder to the root level of either hard disk, so that OpenDoc will be able to access the Editors folder regardless of which volume you start up from.
Your installer script (you are creating an installer script for your product, aren’t you?) should allow the user to choose which volume to install your editors on. The installer script should default to installing your editors on the system startup volume, in the Editors folder (which is located within the System Folder). However, if the user chooses another volume for your editors, the script should install them in an Editors folder at the root of that volume.
That’s all for this month. We look forward to hearing from you and giving others an opportunity to learn from your experiences! If you don’t have the OpenDoc Programmer’s Guide, you can find an Adobe Acrobat version on the OpenDoc DR5 CD or on the World Wide Web.
